Part C:

Developing End-to-End

RESTful Web service project

1

C.1 RESTful APIs

2

What are we covering in this session

● Role of APIs

○ Standardizing APIs

● Introduction to REST

○ Designing APIs REST way (semantics of REST)

○ Documenting APIs first

○ HATEOS

● Alternatives to REST

○ RPC, SOAP, WebSockets, GraphQL

● Systems & Applications are no use in isolation

● System should talk to other systems

● APIs connect systems in the ecosystem

● APIs are the Ears, Nose, Eyes, Mouth, Voice of

a System

● APIs extend the system

Role of APIs

REpresentational State Transfer

updated

data

PATCH

RESTful principles

1. Client & Server

2. Resources have Uniform Interface

3. Client & Server communication is stateless

4. Communication is Cacheable

5. Resources have Layered Servers

6. Code on Demand

GET http://example.com/resources/:id

API Signature

● HTTP Method

● URI

● Input Format

● Response Format

● GET, POST, PATCH

● /resources/:id

● XML, JSON

Let’s Design APIs

Design APIs for an online system to manage the session scheduling

Remote participants attend live session online at scheduled date & time, there can

be multiple such sessions happening concurrently with different set of speakers &

participants, each session has its own Rooms/Studio/Session link, during the

session people chat or discuss about the context of the live session.

Let’s Design APIs - Contd.,

1. Domain Model

2. Identify Domain Resources

3. Identify Essential API Requests

4. API Signatures (URI, Input, Response)

Documenting APIs first

● Document API Signature

● Define Input structure

● Define Response structure

● Allow APIs to be tested/try

Best Practices of RESTful APIs

● Document first & Review with stakeholders

● TDD

● Graceful error messages

● Envelope Pattern for responses

● API Gateway

● Versioning APIs, Backward Compatibility,

Deprecation

Alternatives to REST

● RPC

● SOAP

● WebSockets

● GraphQL

C.1 RESTful APIs - Part II

13

Scope for hands on session

1. Analyze & Design Domain Model for a given problem

2. Define Data Model

3. Identify Queries

4. Identify APIs, URI Semantics, Input & Output data structure

5. Document the APIs using Swagger

6. Create a project structure and development environment & test

7. TDD based implementation of few of APIs

8. Organize project around MVC and separation of concern

9. Support logging, configuration, error handling, global error handling

10.Ensure no lint errors

11.Try out from swagger

References

● [Role of APIs in Enterprise system integration](https://martinfowler.com/articles/enterpriseREST.html)

● [Different levels of maturity possible for RESTful Web Services](https://martinfowler.com/articles/richardsonMaturityModel.html)

● [Detailed but boring video on RESTful Web Application](https://www.youtube.com/watch?v=CvtHSv8Z898) PS : watch in 1.25 speed

● [Some sample APIs](https://developer.github.com/v3/projects/cards/)

● [Sample API documentation using swagger](https://developers.zomato.com/documentation)

● [Sample static API documentation](https://seller.flipkart.com/api-docs/listing-api-docs/LMAPIRef.html#lmapiref-v2-label)

● [Sample swagger enabled NodeJS code](https://github.com/rajiff/swaggerNodeJSDemo)

● [Document APIs first approach blog](https://medium.com/@basavarajkn/design-apis-first-in-node-js-using-swagger-d9f1d5117470)

Design APIs for an online Blogging site

Users registers and create blogs for a specific topic, each blog gets a

unique link to it, which is used for sharing, book marking.

Author of the blog can edit it

Other users can view, comment/reply, search blogs by topic, title, tags

and author

Review the designed APIs using Swagger API Documentation

Exercise

C.2 Organizing Project

Code

17

What are we covering in this session

● Separation of Concern (SoC)

○ Layered, MVC, Distributed

○ Evolving independently

○ Reducing Code conflicts

○ How to do it in NodeJS Backend

● Organizing project to complement SoC

Separating Concerns

● Interfacing

● Authentication, Authorization

● Validation, Parsing

● Processing Business Logic

● Data interaction

● Data Persistence

Suggested Project Organization for NodeJS

● App

● Route

● Controller

● Service

● DAO

● Service

○ Does specific and

individual/independent step of

workflow (business logic)

● DAO

○ Does specific and

individual/independent data

interaction

● Router

○ Specific to framework

○ Parse & Validate input

○ Chain request handlers

(especially for Auth)

● Controller

○ Authenticate, Authorize

request

○ Control the workflow

Role

References

● [Slicing project structure](https://www.aptude.com/blog/entry/understanding-software-development-with-vertical-slices-vs-horizontal-

slices)

● [Feature based slicing](https://blog.risingstack.com/node-hero-node-js-project-structure-tutorial/)

● [Slicing across layers for fullstack](https://agileforall.com/vertical-slices-and-scale/)

● [Why modules are vertically organized, to match vertical Agile stories](http://www.deltamatrix.com/horizontal-and-vertical-user-stories-

slicing-the-cake/)

Organize the Code based on the structure suggested for the APIs

designed in section C1. RESTful APIs

Exercise

C.3 Logging, Configuration

24

What are we covering in this session

● Why Logging is Important

○ How to do it in NodeJS

● Configuration

○ Why is it important to maintain environment wise

○ How to do it in NodeJS

Logging in NodeJS

● Ability to on/off/set specific level of logging

● Trace, Debug, Error, Info

● Save logs to a file, rolled by date & time

● Libraries

○ winston

○ log4js

○ Bunyan

Using Log4js

● Application runs on many environments

○ Local development

○ Team’s Development server

○ QA, Stage

○ Live

● Code should not be changed for environment

● Libraries

○ .ENV (Dot ENV)

○ Config

○ Convict

Configuration in NodeJS

Custom Environment specific config